На сайте проекта VMware Labs вышла обновленная версия средства HCIBench 2.8.1, предназначенного для проведения комплексных тестов производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.8 мы писали вот тут.
Давайте посмотрим, что нового в HCIBench 2.8.1:
Добавлена поддержка нескольких параметров учетных записей для серверов ESXi
Поля для коэффициентов сжатия и дедупликации добавлены для страниц Vdbench и Fio
Оптимизированная функция Easy-Run - добавлены коэффициенты compression/deduplication при тестировании датастора vSAN с включенным режимом dd/c
Многие пользователи применяют сценарии PowerCLI (недавно, кстати, вышла 13-я версия этого пакета) для автоматизации виртуальной инфраструктуры VMware vSphere на базе фреймворка PowerShell.
При этом для скриптов часто встает вопрос безопасного хранения данных учетных записей (логин-пароль), чтобы не указывать их прямым текстом в исходниках сценариев. Компонент PowerCLI credential store использует хранилище учетных записей, которое, в свою очередь, использует Windows data protection API для шифрования данных учетных записей и хранения их в файле. Поэтому PowerCLI credential store доступен только в Windows и не является кроссплатформенным. А что насчет пользователей Linux и MacOS?
Некоторое время назад Microsoft выпустила два полезных кроссплатформенных модуля SecretManagement и SecretStore (подробнее об этом тут). SecretManagement предоставляет командлеты, которые позволяют пользователям управлять паролями в различных хранилищах, а SecretStore - это, собственно, само хранилище и есть. Эти два модуля можно использовать вместо стандартного хранилища VICredential. Чтобы проиллюстрировать, как работать с ними, в VMware сделали пример модуля с разными версиями командлетов VICredential.
Первый шаг - это регистрация и конфигурация защищенного хранилища. В примере использования модуля, упомянутом выше, можно использовать Initialize-VISecret, который реализует эту процедуру - регистрирует SecretStore как хранилище по умолчанию и настраивает окружение так, чтобы пароль не запрашивался при доступе к хранилищу.
function Initialize-VISecret {
[CmdletBinding()]
param(
[string]$Vault = "VMwareSecretStore"
)
Этот режим по пользовательскому опыту близок к VICredentialStore, так как пароли хранятся в зашифрованном виде, но сам пароль при доступе к нему не запрашивается. В примере используется SecretStore по умолчанию, но можно изменить хранилище на любое по вашему выбору, а именно:
Чтобы сохранить креды в хранилище, нужно использовать командлет Set-Secret модуля SecretManagement. Сами креды в этом командлете идентифицируются по имени, но в примере ниже креды описываются двумя идентификаторами - имя пользователя и сервер, к которому нужно получить доступ. Такими образом, командлет New-VISecret склеивает строки "VISecret", сервер и имя пользователя в один идентификатор, который и используется для получения пароля.
Если вы хотите сохранить креды более чем для одного продукта, вы можете изменить функцию так, чтобы заменить VISecret на другую специфичную для продукта строку, чтобы создать идентификатор, например, "VMCSecret" для VMware Cloud. Можно передавать пароль простым текстом или в виде защищенной строки.
Также вы можете удалить креды из хранилища, используя командлет Remove-VISecret, который создает идентификатор и вызывает функцию Remove-Secret для удаления кредов. Если вы используете SecretStore в качестве хранилища, вы можете очистить его полностью с помощью функции Reset-SecretStore.
Создание нового идентификатора выглядит так:
function New-VISecret {
[CmdletBinding()]
[Alias("Set-VISecret")]
param (
[Parameter(Mandatory=$true)]
[string]$Server,
[Parameter(Mandatory=$true)]
[string]$User,
[string]$Password,
[securestring]$SecureStringPassword,
[string]$Vault
)
begin {
if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
Throw "Either Password or SecureStringPassword parameter needs to be specified"
}
if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
}
}
process {
$params = @{
"Name" = "VISecret|"+$server+"|"+$User
}
if ($password) {
$params += @{"Secret" = $password}
} elseif ($secureStringPassword) {
$params += @{"SecureStringSecret" = $secureStringPassword}
} elseif ($Vault) {
$params += @{"Vault" = $Vault}
}
Set-Secret @params
}
}
Последний командлет в примере - это Connect-VIServerWithSecret. Он сочетает в себе оба командлета, приведенных выше, что дает интегрированный инструмент для работы по аналогии с командлетом Connect-VIServer для VICredentialStore. Вы можете вызвать Connect-VIServerWithSecret с логином и паролем, но использовать параметр -SaveCredentials для сохранения кредов в хранилище.
После этого вы можете опускать параметры учетной записи, а Connect-VIServerWithSecret будет автоматически получать пароль из хранилища и соединяться с сервером vCenter. При использовании VICredentialStore, если у вас сохранены креды только к одному серверу, вы можете соединяться с ним через Connect-VIServer без указания имени пользователя. А для использования функции Get-Secret параметр -Username является обязательным, так как не проверяется, что в хранилище сохранена только одна учетная запись. Чтобы упростить жизнь в этом случае есть глобальная переменная $global:defaultUser, значение которой и будет использоваться в Connect-VIServerWithSecret.
На днях компания VMware объявила о доступности бета-версии своей операционной системы Photon OS 5.0. Напомним, что эта ОС на базе Linux используется во всех виртуальных модулях (virtual appliances), выпускаемых и поддерживаемых VMware. О прошлой версии Photon OS 4.0 revision 2 мы писали вот тут.
Давайте посмотрим на основные нововведения Photon OS 5.0:
cgroupsv2 включен по умолчанию в Photon OS 5.0 Beta
Администраторы могут обновлять запущенное ядро без необходимости перезагрузки системы (функция Kernel Live Patching)
Контейнеры теперь могут быть запущены под непривилегированным пользователем, что улучшает безопасность (containerd rootless support)
pmd-nxtgen предоставляет систему конфигураций и мониторинга на базе API для системных служб, таких как systemd, networking, user management, package management и других
network-config-manager консолидирует и упрощает конфигурацию сети и некоторые административные процедуры
Появилась поддержка файловых систем XFS and BTRFS
Ядро Photon OS 5.0 имеет поддержку процессоров Intel Sapphire Rapids
Ядро Linux RT Kernel позволяет обеспечить высокую производительность с малыми задержками, также повысилась стабильность и дополнительные возможности отладки для разработчиков
Были обновлены критичные пакеты, такие как linux, gcc (12.2), glibc(2.32), systemd (252.4), python(3.11.0) и другие
Одновременно с выпуском VMware Photon OS 5.0 было объявлено о прекращении поддержки Photon OS 2.0 (End of Support).
Скачать VMware Photon OS 5.0 Beta и другие компоненты, относящиеся к этому дистрибутиву, можно по этой ссылке.
Недавно мы писали о выходе новой версии фреймворка для автоматизации операций в виртуальной инфраструктуре средствами сценариев VMware PowerCLI 13. Одной из его частей является модуль Horizon PowerCLI module, с помощью которого можно управлять различными аспектами VDI-инфраструктуры. Сегодня мы посмотрим, как это делается.
Модуль PowerCLI для Horizon служит прослойкой для управления конфигурациями виртуальной инфраструктуры десктопов посредством View API, который можно также использовать и путем прямого доступа. Помимо этого, в рамках инструментария по управлению VDI-cредой есть и набор дополнительных функций, доступных в репозитории на GitHub.
В дополнение к View API, инфраструктура Horizon также предоставляет и RESTful API, который называется VMware Horizon Server API. Он предназначен для взаимодействия с Connection Server (подробнее об этом можно прочитать тут).
Итого, мы имеем три основных набора инструментов:
Для начала работы с Horizon через PowerCLI вам нужно выполнить следующие действия:
Устанавливаем VMware PowerCLI
Загружаем и устанавливаем advanced functions
Обращаемся к документации
1. Установка VMware PowerCLI
Основные инструкции по установке находятся здесь. Для начала установки просто открываем Windows PowerShell Admin console и выбиваем команду:
Install-Module VMware.PowerCLI
Далее разрешаем локальное исполнение сценариев командой:
Set-ExecutionPolicy RemoteSigned
2. Установка Advanced Functions
Идем по этой ссылке в репозиторий на GitHub и загружаем пакет по кнопке Download ZIP:
Распаковываем zip-файл и копируем подпапку Hv.Helper в папке modules в одну из директорий модулей на вашем компьютере. Чтобы узнать нужный путь, нужно проверить переменную окружения $env:PSModulePath. Она может быть одной из следующих:
User specific: %UserProfile%\Documents\WindowsPowerShell\Modules
System wide: C:\Program Files\WindowsPowerShell\Modules
Разблокируем расширенные функции, чтобы их можно было исполнять. В командной строке PowerShell под администратором выполняем следующий набор команд:
dir ‘C:\Program
Files\WindowsPowerShell\Modules\VMware.HvHelper\’ |
Unblock-File
После этого будет создана глобальная переменная DefaultHVServers, которая содержит информацию о подключениях к серверам Horizon Connection Servers. Обратиться к ней можно через $Global:DefaultHVServers.
Самое интересное содержится в свойстве ExtensionData. Давайте назначим его переменной $Services и рассмотрим поближе:
Если вы посмотрите документацию к View API, то сможете понять назначение этих записей. Свойство ExtensionData содержит информацию о доступе к любым функциям View API.
Давайте рассмотрим несколько примеров. Сначала используем простую команду для получения всех серверов Horizon Connection Servers в рамках пода (pod). Команда View API ниже использует сервис ConnectionServer и метод ConnectionServer_List для назначения результатов переменной $hvServers1.
Теперь используем одну из расширенных функций для вывода списка всех виртуальных десктопов, в зависимости от состояния агента Horizon Agent в них. Это полезно, чтобы понять, в нормальном ли состоянии там находятся агенты, или они пришли в некорректное состояние ошибки.
Итак, выводим список десктопов, где юзер залогинен, но в текущей сессии он не присоединен:
Затем вы можете написать свой сценарий, который выводит десктопы, где Horizon Agent находится в одном из перечисленных некорректных состояний. Далее можно предпринять шаги по исправлению ситуации - например, перезагрузить машины, чтобы в некоторых из них ошибка исправилась (к примеру, для статуса AGENT_ERR_NEED_REBOOT).
Сценарий ниже позволяет как раз это и сделать. Вам нужно поменять параметры, специфические для вашей среды, такие как имя Connection Server, пользователь, пароль и другое. Если вы не хотите использовать пароль в открытом виде, то можете убрать его из команд Connect-HVServer и Connect-VIServer - тогда он будет запрошен в интерактивном режиме.
Также обратите внимание на параметр -WhatIf в команде Restart-VMGuest - он позволяет вам получить возможный результат исполнения команды без необходимости ее фактического исполнения.
####################################################################
# Get List of Desktops that have Horizon Agent in problem states.
# Reboot the OS of each of these.
####################################################################
#region variables
###################################################################
# Variables
###################################################################
$cs = 's1-hcs1.mydomain.com' #Horizon Connection Server
$csUser = 'administrator' #Connection Server user
$csPassword = 'mypassword' #Connection Server user password
$csDomain = 'mydomain' #Connection Server domain
$vc = 'vcenter1.mydomain.com' #vCenter Server
$vcUser = 'administrator@vsphere.local' #vCenter Server user
$vcPassword = 'mypassword' #vCenter Server password
$baseStates = @('PROVISIONING_ERROR',
'ERROR',
'AGENT_UNREACHABLE',
'AGENT_ERR_STARTUP_IN_PROGRESS',
'AGENT_ERR_DISABLED',
'AGENT_ERR_INVALID_IP',
'AGENT_ERR_NEED_REBOOT',
'AGENT_ERR_PROTOCOL_FAILURE',
'AGENT_ERR_DOMAIN_FAILURE',
'AGENT_CONFIG_ERROR',
'UNKNOWN')
#endregion variables
#region initialize
###################################################################
# Initialize
###################################################################
# --- Import the PowerCLI Modules required ---
Import-Module VMware.VimAutomation.HorizonView
Import-Module VMware.VimAutomation.Core
Set-PowerCLIConfiguration -InvalidCertificateAction Prompt
# --- Connect to Horizon Connection Server API Service ---
$hvServer = Connect-HVServer -Server $cs -User $csUser -Password $csPassword -Domain $csDomain
# --- Get Services for interacting with the View API Service ---
$services= $hvServer.ExtensionData
# --- Connect to the vCenter Server ---
Connect-VIServer -Server $vc -User $vcUser -Password $vcPassword
#endregion initialize
#region main
###################################################################
# Main
###################################################################
Write-Output ""
if ($services) {
foreach ($baseState in $baseStates) {
# --- Get a list of VMs in this state ---
Write-Host ("Get VMs with baseState: " + $baseState) -ForegroundColor Yellow
$ProblemVMs = Get-HVMachineSummary -State $baseState
foreach ($ProblemVM in $ProblemVMs) {
$VM = Get-VM -Name $ProblemVM.Base.Name
# --- Reboot each of the Problem VMs ---
Restart-VMGuest -VM $VM
# Add -WhatIf to see what would happen without actually carrying out the action.
}
}
Write-Output "", "Disconnect from Connection Server."
Disconnect-HVServer -Server $cs
} else {
Write-Output "", "Failed to login into Connection Server."
pause
}
# --- Disconnect from the vCenter Server ---
Write-Output "", "Disconnect from vCenter Server."
Disconnect-VIServer -Server $vc
#endregion main
Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках. В основном, документ повторяет рекомендации, которые приводились для прошлых версий платформы, но есть и пункты, касающиеся непосредственно vSphere 8 и ESXi 8:
Документ очень полезный, состоит ровно из ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.
Как вы знаете, главным релизом этого года стала новая версия платформы VMware vSphere 8, где появилось множество новых возможностей и улучшений уже существующих технологий. Одной из интересных функций стала vSphere Virtual Topology.
Для виртуальных машин с Hardware version 20 теперь доступно простое конфигурирование vNUMA-топологии для виртуальных машин:
Для виртуальных машин теперь доступна информационная панелька CPU Topology с конфигурацией vNUMA:
Недавно компания VMware выпустила документ "vSphere 8.0 Virtual Topology Performance Study", где рассматриваются аспекты производительности новой технологии, которую назвали vTopology. Виртуальная топология CPU включает в себя такие техники, как virtual sockets, узлы virtual non-uniform memory access (vNUMA), а также механизм кэширования virtual last-level caches (LLC).
До vSphere 8.0 дефолтной конфигурацией виртуальных машин было одно виртуальное ядро на сокет - это в некоторых случаях создавало затыки в производительности и неэффективность использования ресурсов. Теперь же ESXi автоматически подстраивает число виртуальных ядер на сокет для заданного числа vCPU.
На картинке ниже показана высокоуровневая архитектура компонентов двухсокетной системы. Каждый сокет соединен с локальным узлом памяти (memory bank) и образует с ним NUMA-узел. Каждый сокет имеет 4 ядра (он имеет кэши L1 и L2), а ядра шарят между собой общий кэш last-level cache (LLC).
Когда создается виртуальная машина с четырьмя vCPU, в vSphere она конфигурируется на одном сокете, вместо четырех, как это было ранее:
Так это выглядит в выводе команды CoreInfo для двух рассмотренных топологий:
Слева - это старая конфигурация, где был один vCPU на сокет, а справа - 4 vCPU (виртуальных ядер ВМ) на один сокет.
В указанном документе VMware проводит различных конфигураций (от 8 до 51 vCPU на машину) для разных нагрузок с помощью бенчмарков и утилит DVD Store 3.5, Login VSI, VMmark, Iometer, Fio и Netperf в операционных системах Windows и Linux. Забегая вперед, скажем, что для нагрузок Oracle прирост производительности составил 14%, а для Microsoft SQL server - 17%.
Итак, результаты теста DVD Store для БД Oracle:
Статистики NUMA hits NUMA misses для гостевой ОС Linux:
Результаты тестов для Microsoft SQL server:
Результаты тестирования хранилищ с помощью IOmeter:
Производительность в разрезе метрики CPU cycles per I/O (CPIO):
Некоторое время назад мы писали о том, что линейка продуктов VMware vRealize превратилась в VMware Aria, а решение vRealize Log Insight стало носить название Aria Operations for Logs. Напомним, что этот продукт представляет собой платформу для аналитики лог-файлов, мониторинга и решения проблем инфраструктуры в облаке.
Сегодня мы поговорим о том, как использовать API-вызовы в сценариях PowerCLI для выполнения операций в Aria Operations for Logs.
Итак, сначала вам нужно получить API-токен с портала Cloud Services Portal (CSP). Заходим в настройки аккаунта в раздел API Tokens и генерируем новый:
При создании токена нужно задать его имя, время жизни и к каким компонентам облачной инфраструктуры будут иметь доступ операции с использованием этого токена. Выбираем компонент vRealize Log Insight Cloud Admin и нажимаем Generate внизу экрана:
После этого появится всплывающее окно, где можно скопировать новый токен - его следует сохранить в безопасное место.
Теперь можно использовать сценарии PowervRLI. Сначала нужно установить командлеты из Powershell Gallery с помощью следующей команды (это можно также сделать и в офлайн режиме с помощью инструкций, доступных на GitHub):
После этого вам нужно ввести API-ключ токена, полученный из CSP, после выполнения команды Connect-vRLI-Cloud. Далее произойдет соединение с облачным инстансом Aria Logs:
Вы можете выполнить команду Get-AlertDefinitions для получения списка алертов Aria Logs, чтобы команда аудита имела возможность понимать, какие события могут происходить. Вывод можно экспортировать в файл, чтобы он был доступен членам команды.
Теперь выполним запрос через API, чтобы получить некоторые события из окружения Aira Logs. Запросы нужно писать в формате SQL, которые указываются в качестве переменной:
После этого будет сгенерирован вывод команды, который можно послать для ревью и анализа:
В этом году компания VMware в рамках анонсов конференции Explore 2022 выпустила новые версии платформ vSphere 8 и vSAN 8. Главным нововведением новой версии vSAN стало решение Express Storage Architecture. Это новая архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).
Традиционно, в vSAN одним из фундаментальных понятий были дисковые группы. Это объединения дисков на хостах ESXi, которые используются для функций хранения (Capacity tier) и кэширования (Caching tier). Необходимо было это для того, чтобы пользователи могли гибко управлять ресурсами HDD и SSD дисков с точки зрения емкостей (дешевле использовать HDD) и производительности кэша (лучше использовать SSD).
Так как архитектура ESA предназначена для высокопроизводительных хранилищ на SSD/NVMe носителях, то необходимость использования дисковых групп отпала - вместо них появился объект Storage Pool. Теперь пользователю не нужно указывать, какие диски будут использоваться для кэширования, а какие для хранения - все они вносят вклад, как в подсистему хранения, так и в подсистему кэширования на паритетной основе (операции ввода-вывода распределяются между устройствами равномерно, не создавая бутылочного горла).
Идея vSAN в том, чтобы обеспечивать скорость чтения на уровне RAID-1, а эффективность использования дискового пространства на уровне RAID-5 / RAID-6. Подсистема работы с хранилищами оптимизирована таким образом, что сейчас поддерживается память TLC, но и сделаны оптимизации для будущих устройств QLC. Об этом рассказал Дункан Эппинг.
Ключевые элементы новой архитектуры - это файловая система log-structured filesystem и специальный durable log. Давайте посмотрим на картинку:
Все данные, которые отправляются на запись в log-structured file system, сначала попадают в durable log. Это позволяет убедиться в том, что данные сохранятся персистентно. Этот durable log является частью блока Performance Leg, который спроектирован для того, чтобы операции записи сохранялись быстро и в первую очередь.
Performance Leg представляет собой конфигурацию уровня RAID-1, принимающую операции записи, которые мгновенно подтверждаются со стороны хранилища, а потом на нижнем уровне данные распределяются уже как избыточный страйп (RAID 5/6) на Capacity Leg. Для этого Performance Leg собирает stripe write размером 512 КБ и отсылает эти блоки на Capacity Leg, ну а для подстраховки этих процессов на случай сбоев у нас всегда есть durable log. Такая схема позволяет достичь наилучшего баланса с точки зрения производительность/доступная емкость в VMware vSAN 8.
Ну и посмотрите интересное видео от Дункана на эту тему:
На этой неделе компания VMware выпустила обновление своего фрейморка для управления виртуальной инфраструктурой PowerCLI 13. Напомним, что о версии PowerCLI 12.7 мы писали в июле этого года вот тут.
Давайте посмотрим, что нового появилось в VMware PowerCLI 13:
1. Первая полностью кросс-платформенная версия
В тринадцатой версии PowerCLI был завершен переход к полной кросс-платформенности, который начался еще в 2018 году, когда Microsoft выпустила первую мультиплатформенную версию PowerShell. С тех времен множество модулей было портировано на другие платформы, и сейчас удалось достичь полного соответствия доступных командлетов на всех платформах.
Завершился этот процесс портированием последних двух модулей ImageBuilder и AutoDeploy, которые ранее были доступны только для Windows.
Так как Python требуется для ImageBuilder, команда PowerCLI решила его больше не включать в состав пакета, но теперь Python версии 3.7 является обязательным требованием для использования именно модуля ImageBuilder. Также вам потребуется установить и несколько дополнительных пакетов для Python (six, psutil, lxml, pyopenssl). В PowerCLI User’s Guide теперь есть инструкции о том, как установить все эти компоненты на поддерживаемых платформах.
Кроме того, в PowerCLI теперь есть настройка, которая указывает путь к инсталляции Python. Вы можете использовать следующую команду:
Set-PowerCLIConfiguration -PytonPath "<path to the Python installation>"
2. Обновление модуля VMware Cloud Director
Теперь в плане поддержки vCD в PowerCLI 13 было сделано несколько улучшений. Во-первых, появилась поддержка vCD 10.4, а также поддержка API-функций vCD 10.4 (API версии 37.0). Во-вторых, в некоторые командлеты были добавлены новые параметры и наборы параметров. Например, в командлете New-CIVM появился набор параметров, который позволяет создать пустую виртуальную машину, а также командлет New-OrgVdc с параметром -StorageProfile.
Также командлет Get-NetworkPool был расширен - теперь можно получать пулы для инсталляций NSX-T. Ну и некоторые API изменились - теперь вместо командлета Get/New/Set/Remove-OrgNetwork актуален командлет Get/New/Set/Remove-OrgVdcNetwork, который был добавлен уже достаточно давно.
3. Поддержка архитектуры VMware vSAN Express Storage Architecture (ESA)
Напомним, что в новой версии VMware vSAN 8 появилась новая архитектура Express Storage Architecture (ESA). Теперь было добавлено несколько новых командлетов (Get-VsanEsaEligibleDisk и Add/Get/Remove-VsanStoragePoolDisk), а также расширены некоторые уже существующие (New/Set-Cluster and Get-VsanClusterConfiguration), чтобы обеспечить поддержку vSAN ESA.
4. Обновления модуля NSX
Чтобы обеспечить пользователей информацией об использовании нового модуля NSX SDK в руководство owerCLI user’s guide была добавлена отдельная глава. Также в PowerCLI 13 был убран старый способ доступа к NSX API через командлеты Get-NsxtPolicyService, Get-NsxtGlobalManagerService и Get-VmcSddcNetworkService.
5. Улучшения поддержки HCX
В PowerCLI 13 появилось несколько новых возможностей в плане поддержки решения VMware HCX. Теперь модуль HCX позволяет включить seed checkpoint, а также смигрировать кастомные атрибуты виртуальных машин.
При апгрейде с прошлых версий на PowerCLI 13 через Update-Module вы можете столкнуться с ошибкой (подробнее тут). Это потому, что сертификаты для подписки модулей были изменены - они подписаны другим издателем. Чтобы обойти проблему, просто удалите старый модуль и переустановите его с помощью командлета Install-Module.
Скачать VMware PowerCLI 13 можно по этой ссылке (а Release Notes находятся здесь). Установка модуля происходит командой:
Давайте посмотрим, что нового в VMware Workstation 17 Pro и Player:
1. Поддержка ОС Windows 11
Теперь Windows 11 можно использовать как в качестве хостовой, так и в качестве гостевой ОС на системах x86_64 CPU. В этом случае платформу Workstation можно развернуть в ОС Windows и Linux. Для этого были добавлены функции Virtual Trusted Platform Module и Fast Encryption.
2. Работа с Virtual Trusted Platform Module и Fast Encryption
Чтобы обеспечить поддержку Windows 11, от физической системы или платформы виртуализации требуется поддержка механизма Trusted Platform Module. В этом релизе для работы Virtual TPM module (vTPM) были добавлены некоторые функции. В частности, vTPM имеет реализацию механизма Fast Encryption, который предполагает шифрование только критических частей виртуальных машин и их локальных хранилищ, что намного ускоряет производительность ВМ, практически не уменьшая уровень безопасности (включается это в меню VM Settings > Encryption). Второй момент - это автогенерация паролей для пользователя и использование локального keychain для хранения ключей шифрования, что освобождает пользователя от необходимости вводить пароль при каждой загрузке ВМ.
3. Autostart VMs
Это возможность настроить виртуальные машины, которые включаются сразу после того, как загружается хостовый компьютер.
4. Функции шифрования для Workstation Player
Чтобы реализовать vTPM, поддерживаемый в Windows 11, функции VM encryption были добавлены и в Workstation Player, чтобы он позволял создавать ВМ на платформе Windows 11.
5. Поддержка графики OpenGL 4.3
Версии Workstation for Windows и Linux при использовании с ВМ Linux с версией kernel 5.18 или более новой и Mesa 22.1.1+, а также ВМ с ОС Windows на борту, используют версию OpenGL 4.3 и OpenGL ES 3.10, что повышает качество графической подсистемы.
6. Поддержка новых гостевых систем
Список поддерживаемых гостевых ОС в VMware Workstation 17 пополнился следующими:
Windows 11
Windows Server 2022
Ubuntu 22.04, 20.04, 22.10
Debian 11.5, 12,
Fedora 37, 36,
RHEL 9
FreeBSD 12, 13
7. Поддержка драйверов WDDM
Теперь Workstation Pro поддерживает пакет графических драйверов WDDM (Windows Display Driver Model) версии 1.2 для виртуальных машин.
8. Обновление библиотек безопасности
В составе продуктов Workstation и Player в этом релизе используются следующие версии библиотек различных компонентов:
OpenSSL 1.1.1q
Python 3.10.4
Libgcrypt 1.10.0
zlib 1.2.12
Expat 2.4.9
Скачать VMware Workstation 17 Pro и Player можно по этой ссылке.
Таги: VMware, Workstation, Update, Windows, Player
Недавно компания VMware анонсировала новый тип инстанса для самых тяжелых нагрузок в публичном облаке VMware Cloud on AWS - AWS-i4i.metal. Теперь пользователи могут выбрать один из трех типов инстансов, каждый из которых заточен под определенный профиль задач:
В VMware недавно провели тестирование СУБД Microsoft SQL Server в облаке VMConAWS с помощью инструмента DVD Store, который измеряет производительность баз данных в числе выполненных операций в минуту (orders per minute, OPM).
Для целей тестирования было создано 3 кластера, каждый из трех соответствующих инстансов, которые отрабатывали нагрузки SQL Server:
Для начала была протестирована производительность SQL Server на одной машине каждого из кластеров. Результат получился таким:
Инстанс I4i производительнее I3 на 158% (более, чем в 2.5 раза)
I3en производительнее I3 на 52%
Далее тестовая нагрузка была запущена на двух хостах каждого кластера:
Как мы видим, производительность выросла почти в два раза с примерно одинаковыми потерями для каждого из кластеров. То есть масштабируется эта рабочая нагрузка в облаке VMConAWS хорошо.
Ну и результат при запуске теста на всех трех хостах для каждого из кластеров:
Здесь коэффициент масштабирования по производительности в отношении одного хоста составил 2.6-2.9x, что очень и очень неплохо.
Инстанс I4i показывает себя хорошо как для задач общего назначения, так и для специфических нагрузок, таких как реляционные СУБД (Microsoft SQL Server, Oracle Database, MySQL) и NoSQL базы данных (MongoDB, Couchbase, Aerospike, Redis), а также VDI нагрузки.
Описание тестового окружения представлено на картинке ниже:
Недавно компания VMware представила расширение для сервис-провайдеров, предоставляющих услуги по аренде виртуальных машин из облака - VMware Cloud Director extension for VMware Data Solutions 1.0. Этот продукт, доступный провайдерам бесплатно, представляет собой плагин для Cloud Director, который реализует возможности по кэшированию, обработке сообщений и различные программные сервисы для больших проектов.
Это дает разработчикам инструменты по имплементации нативных облачных сервисов на базе инфраструктуры IaaS провайдера услуг, который предоставляет их через Cloud Director.
В первой версии расширения доступна поддержка самого распространенного потокового брокера сообщений RabbitMQ. В самое ближайшее время будет добавлена поддержка и других приложений из портфеля VMware Data Solutions.
С помощью RabbitMQ можно создавать потоковые очереди сообщений в различных сервисах, обрабатывающих события, которые позволяют реализовывать высоконагруженные распределенные приложения.
Получить доступ к плагину можно из консоли Cloud Director:
Для клиентов облака провайдеры могут публиковать различные сервисы, в данном случае RabbitMQ, и назначать роли пользователям:
Также провайдеры могут создавать, публиковать и управлять шаблонами RabbitMQ, которые представляют собой набор предустановленных параметров для создания инстансов сервиса под клиентов облака.
На картинке ниже виден пример шаблонов с метками, которые опубликованы провайдером для своих клиентов. Клиенты же могут кастомизировать предоставленные им шаблоны, исходя из требований своих приложений.
Клиенты облака могут создать экземпляр сервиса с использованием шаблонов. Первый способ - это использовать готовый шаблон, предоставленный провайдером. Нужно просто выбрать сам шаблон и кластер для развертывания:
Вторая опция - это кастомизация шаблона на базе YAML-файлов, которую поддерживает Management Console:
Также в интерфейсе есть дэшборд, которые дает представление по всем инстансам с деталями о том, какие сервисы развернуты (сейчас пока только RabbitMQ):
Пользователь может просматривать экземпляры решений на вкладке Solutions:
Также здесь можно просматривать и мониторить инстансы RabbitMQ, которые были развернуты с помощью плагина. Консоль также дает возможность открыть интерфейс Grafana для выбранного инстанса:
При открытии интерфейса Grafana это будет выглядеть так:
Решение доступно для сервис-провайдеров бесплатно, но они должны сообщать в VMware информацию о потреблении ресурсов сервисов Data Services (на данный момент только RabbitMQ).
Скачать VMware Cloud Director extension for VMware Data Solutions 1.0 можно по этой ссылке. Release Notes доступны тут.
На прошедшей в конце лета конференции Explore 2022 компания VMware представила множество новых продуктов и технологий. Некоторые из них можно назвать "VMware Projects" - это те анонсированные продукты, которые находятся в ранней стадии разработки и будут представлены в будущем как часть существующих платформ или как отдельные решения. О них мы сегодня и поговорим.
На сайте проекта VMware Labs обновилось средство HCIBench до версии 2.8.0. Напомним, что оно предназначено для проведения комплексных тестов производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.6 мы писали вот тут.
Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.
Давайте посмотрим, что нового в HCIBench 2.8.0:
Компонент fio обновлен до версии 3.30
Добавлен целевой параметр latency для fio
Исправлена уязвимость CVE-2021-40438
Добавлен vSAN support bundle graph для режима vSAN Debug mode
Улучшен отчет об использовании ресурсов
Добавлена поддержка возможности тестирования vSAN 8 ESA
Исправлена ошибка при тестировании на архитектуре VMware Cloud
В начале года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз до этого о нем мы упоминали вот тут.
Выглядел он тогда так:
И вот на днях компания VMware объявила о выпуске новой версии продукта VMware vCenter Converter Standalone 6.3.0, который поддерживает миграцию на платформу VMware vSphere 7, включая ее пакеты обновлений. К сожалению, поддержки vSphere 8 мы пока не получили (хотя технически перевести туда виртуальную машину с помощью Converter не очень-то сложно).
Давайте посмотрим на новые возможности Converter 6.3.0:
1. Обновился список поддерживаемых физических платформ для установки Converter
Теперь для целей P2V (Physical-to-Virtual) и V2V (Virtual-to-Virtual) миграции вы можете установить конвертер на следующие десктопные и серверные системы:
Windows Server 2012 (64-bit)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
2. Обновился список поддерживаемых гостевых ОС для конвертации
Теперь с помощью vCenter Converter вы можете перенести в виртуальную среду vSphere виртуальные и физические машины под управлением следующих операционных систем:
Windows Server 2012 (64-bit)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
CentOS 6.x (32-bit and 64-bit)
Red Hat Enterprise Linux 6.x (32-bit and 64-bit)
Red Hat Enterprise Linux 7.x (64-bit)
Ubuntu 14.04 LTS (32-bit and 64-bit)
Ubuntu 16.04 LTS (32-bit and 64-bit)
Внимание! При переносе следующих файловых систем машин Linux их файловые системы будут сохранены:
ext2
ext3
ext4
reiserfs
vfat
xfs
Все остальные ФС будут сконвертированы при миграции в ext3 или ext4 на целевой виртуальной машине.
3. Обновился список поддерживаемых платформ для V2V-миграции
Теперь можно переносить в среду vSphere виртуальные машины под управлением гипервизора Hyper-V на следующих платформах Microsoft:
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
4. Поддержка целевых платформ VMware
Теперь виртуальные и физические машины можно перенести на следующие платформы VMware:
VMware vSphere 6.5 (Update 3)
VMware vSphere 6.7 (Update 3)
VMware vSphere 7.0
VMware vSphere 7.0 (Update 1)
VMware vSphere 7.0 (Update 2)
VMware vSphere 7.0 (Update 3)
VMware Workstation 16.x
VMware Fusion 12.x
5. Программа Customer Experience Improvement Program
Теперь продукт vCenter Converter участвует в программе CEIP, что подразумевает сбор информации о пользовательских окружениях в целях улучшения их опыта. В рамках CEIP собирается следующая информация о виртуальной среде:
Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и численных значений (отклик интерфейса, детали об API-вызовах и прочее).
Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP, то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.
Несколько важных моментов при использовании vCenter Converter:
Converter Standalone 6.3.0 не поддерживает версии Virtual Hardware выше 11. У целевых машин возможности будут ограничены именно этой версией виртуального железа. Дальнейший апгрейд вам надо делать самостоятельно.
Пока поддерживается только размер секторов 512B (512e и 512n). Нативные 4K-диски (4Kn) не поддерживаются.
Converter Standalone 6.3 поддерживает только те ОС RHEL 6.x и CentOS 6.x, которые используют SSH-ключи с аутентификацией RSA SHA1. Новые алгоритмы, такие как RSA SHA2 или ECDSA, не поддерживаются.
Скачать VMware vCenter Converter Standalone 6.3.0 можно по этой ссылке. Release Notes доступны тут.
Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.
Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.
Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.
Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).
Итак для этого вам понадобятся:
Действующий vCenter Server не ниже седьмой версии
Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.
Пример исполнения сценария показан ниже:
В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:
Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:
Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.
Не секрет, что являясь конкурентами в плане технологий виртуализации, компании VMware и Microsoft также ведут и сотрудничество. Как раз результатом такого сотрудничества и стала интеграция драйверов VMware Paravirtual SCSI controller (PVSCSI) в операционную систему Microsoft Windows 11, начиная с версии 2H22 (выпущена 20 сентября этого года).
Раньше при установке гостевой ОС в виртуальной машине на дисках PVSCSI система Windows просто не видела диски на этом контроллере, поэтому установить ее на них было нельзя. Теперь же на шаге обнаружения диска и сетевых устройств (виртуальный сетевой адаптер с драйверов VMware VMXNET3) вы можете их увидеть в рамках рабочего процесса Windows Out of Box Experience (OOBE):
Между тем, это вовсе не значит, что после установки операционной системы вы не должны устанавливать пакет VMware Tools. Его обязательно нужно поставить, так как он содержит не только драйверы устройств, но и другие важные вспомогательные инструменты.
Также драйверы VMware Paravirtual SCSI и VMware VMXNET3 теперь включены в обновления Windows Updates:
Для получения более подробной информации об интеграции службы обновлений Windows и драйверов VMware вы можете воспользоваться статьей KB 82290 или поиском в Microsoft Update Catalog.
В конце лета этого года компания VMware провела конференцию Explore 2022, где представила новую версию решения для создания отказоустойчивых хранилищ VMware vSAN 8. Главным нововведением обновленной платформы стала архитектура Express Storage Architecture (ESA), которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения. Сегодня мы посмотрим, какие улучшения механизма работы снапшотов появились в vSAN, работающем в ESA-варианте.
Еще много лет назад мы писали о том, что снапшоты - это зло, и использовать их нужно с большой осторожностью и при большой необходимости. Например, перед обновлением виртуального аппаратного обеспечения, ОС или критичных приложений можно сделать снапшот, проверить что все в порядке после обновления, а затем удалить его.
Снапшоты, создаваемые для специфических целей администраторов, часто разрастаются в разных ветках, что в итоге приводит к падению производительности виртуальной машины и операционным сложностям при консолидации (например, недостаток места). При этом снапшоты - это вещь нужная для таких процессов, как резервное копирование и автоматизированные рабочие процессы Continuous Integration/Continuous Delivery (CI/CD), Copy Data Management (CDM), а также управление виртуальными ПК VMware Horizon.
Часто в большой инфраструктуре VMware vSphere можно обязательно найти вот такую машину, которая "почему-то тормозит":
Традиционно снапшоты в VMware vSphere строились на базе технологии redo-log (дельта диск отличий от основного VMDK), которая имеет ограничения по масштабируемости и производительности. Снапшоты типа VMFSsparse использовались по умолчанию в файловой системе VMFS5 для дисков менее 2 ТБ и для всех дисков на системах до VMFS5.
VMFSsparse работает поверх VMFS как redo-log, который создается пустым, как только для ВМ создается снапшот, и растет до размера родительского VMDK-диска, накапливая данные. Начиная с VMFS5, для дисков более 2 ТБ и для всех дисков VMFS6 был добавлен формат снапшота VMFS SEsparse. Это эволюционное изменение снапшотов, которое давало улучшения в плане склеивания снапшотов и в отношении их больших цепочек, где ранее происходила потеря производительности.
Также для SEsparse снапшотов было сделано множество улучшений в новых версиях vSphere, например, при чтении данных для машин со снапшотами была существенно увеличена производительность: чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение:
Также были сделаны некоторые оптимизации "подмораживания" (stun) при различного рода операциях со снапшотами, а также специфические технологии, такие как Mirror driver, но концептуально суть снапшотов не поменялась. Поэтому VMware продолжала давать рекомендации не хранить их более 48 часов и не создавать длинных цепочек снапшотов, особенно для критичных нагрузок.
Архитектура снапшотов в vSAN базируется на традиционных redo-log снапшотах, которые были доработаны - так появился формат vsanSparse (начиная с vSAN 6). Он использует механизм redirect-on-write и снижает некоторые технические ограничения снапшотов за счет кэширования, но проблемы подмораживания и долгого времени удаления снапшотов остаются.
В новой версии vSAN 8 при использовании архитектуры ESA, снапшоты используются совершенно другим образом, нежели в прошлых версиях платформы. Вместо использования традиционной цепочки базового и дельта-дисков, механизм снапшотов использует lookup table, применяя структуры B-Tree.
Файловая система log structured file system в vSAN ESA позволяет новым операциям записи помещаться в новые сегменты хранилища с их указателями метаданных, интеллектуально размещая их в соответствии с принадлежностью к снапшотам. В этом случае время удаления снапшота снижается более чем в 100 раз по сравнению с прошлыми версиями платформы vSAN.
Также новая архитектура снапшотов снижает и накладные расходы на вычисления и перемещения данных, которые происходят при удалении снапшотов (а это были одни из самых нагружающих инфраструктуру операций). По-сути, когда в vSAN 8 удаляется снапшот, происходит лишь удаление метаданных, а физического перемещения блоков не происходит.
Мало того, пользователь получает подтверждение удаления снапшота сразу же, а удаление данных и метаданных происходит позже, в асинхронном режиме. Новая архитектура снапшотов ESA позволяет использовать практически неограниченное количество снапшотов - однако текущие параметры платформы vSphere ограничивают число снапшотов числом 32 на один объект.
Как знают администраторы VMware vSphere, решения для резервного копирования используют снапшоты через vSphere Storage API (также называемые VADP) для передачи резервных копий на хранилища. Новая функциональность vSAN ESA автоматически заменит старый механизм снапшотов, а пользователи увидят реальный прирост производительности при консолидации снапшотов, а также при работе продуктов VMware SRM и vSphere Replication в кластерах ESA.
Таги: VMware, vSAN, Update, Snapshots, Storage, ESA, Performance
На прошедшей конференции Explore 2022 компания VMware представляла большие корпоративные продукты, о которых мы пишем вот тут. Но был показан и еще один небольшой исследовательский проект - WebAssembly
(Wasm) - открытый стандарт, определяющий бинарный стандарт исполняемых программ.
Во время демонстрации был показан эксперимент, который ставил своей целью собрать веб-сервер на базе самых дешевых микрокомпьютеров Raspberry Pi Zero W and Pi Zero 2 W. Эти маленькие low-end платы интегрируют в себе чипсеты BCM2835 (ARM 32-Bits / 1GHz) и BCM2710A1 (ARM 64-bits / Quad core 1GHz) и имеют на борту 512MB памяти SRAM. Системы эти очень бюджетные - стоят около $10, они применяются для прототипирования и некоторых прикладных задач.
Технология Server-Side Rendering позволяет обработать клиентскую часть JS на стороне сервера и послать HTML-ответ в браузер. После загрузки специальный компонент берет на себя контроль над веб-страницей, чтобы обеспечить с ней интерактивное взаимодействие, которое называется hydration.
Вот что из этого получилось:
Развертывание веб-сервера производится в 4 простых шага:
1. Логинимся по SSH:
ssh pi@PI_ZERO_IP_ADDRESS
2. Скачиваем и распаковываем контент:
wget https://github.com/vmware-samples/webassembly-browser-apps/releases/download/pi-zero-ssr%401.0.0/build.tar.gz
tar xvf build.tar.gz
3. Запускаем веб-сервер:
# Pi Zero (32-bit):
./ssr-handler ./ssr.wasm ./dist
# Pi Zero 2 (64-bit):
./ssr-handler-64 ./ssr.wasm ./dist
4. Заходим на него:
http://PI_ZERO_IP_ADDRESS:8080
По итогам теста генерация страниц получилась достаточно производительной для 64-битной архитектуры:
Много лет назад мы писали о технологиях работы кэша write-through и write-back в ведущем на рынке виртуализации хранилищ решении StarWind Virtual SAN. С тех пор механика работы этих технологий была улучшена, но принципы остались теми же, как и большинство фундаментальных технологий. Сегодня мы поговорим о работе кэшей уровней L1 и L2, которые существенно улучшают быстродействие операций ввода-вывода.
При работе StarWind Virtual SAN с хранилищами используется кэш первого уровня (L1), располагающийся в оперативной памяти, а также кэш второго уровня (L2), размещенный на SSD-дисках, обеспечивающих высокое быстродействие системы.
StarWind использует традиционную оперативную память серверов (RAM) как буфер на чтение (write buffer) и L1-кэш, чтобы кэшировать операции записи, флэш-память SSD уже обслуживает кэш уровня L2. Оба кэша используют одни и те же алгоритмы - shared library, поэтому информация ниже применима, в основном, к кэшам обоих уровней. Об их отличиях мы также поговорим в статье отдельно.
При переполнении кэша нужно освободить его, используя какой-то алгоритм. StarWind применяет для этого алгоритм LRU - least recently used, то есть вытесняются данные (блоки), которые используются реже всего в последнее время.
В зависимости от степени исчерпания состояния кэша, его блоки могут находиться в одном из трех состояний: dirty, clean и empty. В самом начале блок помечается как empty - в нем нет данных, то есть блоки кэша не ассоциированы с блоками на диске. При работе кэша эти данные начинают заполняться. Блок помечается как dirty - если полезные данные были записаны в него, но еще не были записаны на диск (он не подтвердил запись данных). Блок помечается как clean, если данные из кэша были записаны на диск, либо блок кэша был записан в результате чтения в кэш блока с диска - то есть блок кэша и блок на диске содержат одинаковые данные.
Помните, что стандартный размер блока для кэша - 64 КБ.
Следующее полезное понятие - это прогрев кэша (cache warm-up). Эта концепция имплементируется на нижнем уровне в рамках сценария "in-memory" файловой системы LSFS (log-structured file system). Данные в кэш в этом случае попадают с диска, с учетом самых последних данных, записанных на диск.
Политики кэширования
Политика кэширования определяется вместе с другими параметрами кэша / устройств, когда они создаются. В StarWind Version 8 Release 5 режим работы кэша может быть изменен на лету для уже существующих устройств.
Write-back caching
Это режим, когда запись данных производится в кэш, но операция ввода-вывода (I/O) подтверждается, как запись на диск. Запись в основную память производится позже (при вытеснении или по истечению времени), группируя в одной операции несколько операций записи в соседние ячейки. Этот тип кэширования существенно ускоряет скорость записи данных на диск, однако имеет несколько меньшую надежность с точки зрения записи данных.
Если блок находится в статусе empty или clean, то запись в кэш происходит практически мгновенно, на уровне скорости записи данных в RAM или на SSD. А вот как работает кэш в разных обстоятельствах:
Если операции записи не были сделаны в dirty-кэш на протяжении некоторого времени (по умолчанию 5 секунд), то данные записываются на диск. Блок переходит в состоянии clean, но данные в нем остаются.
Если все доступные блоки кэша находятся в состоянии dirty, то данные, хранимые в самых старых блоках, форсированно скидываются на диск, а новые данные записываются в эти блоки. В этом случае производительность кэша несколько падает из-за требующихся операций записи на диск, и она сравнима со скоростью такой операции с диском.
Если происходит сбой в работе сервера или памяти (или его выключают на обслуживание), то данные в кэше write-back, помеченные как dirty, немедленно сбрасываются на диск. Если размер кэша большой (гигабайты), то эта операция может занять значительное время. Его можно оценить так: Flushing time = cache size / RAM write.
Политика кэширования write-back ускоряет производительность в следующих случаях:
Флуктуации нагрузки - кэш позволяет сгладить пики нагрузки за счет аккумуляции большого числа записей в кэше во время всплесков до момента снижения нагрузки.
Постоянная перезапись тех же самых блоков - в этом случае они постоянно перезаписываются только в кэше, а на диск сбрасываются пачки блоков по мере необходимости.
Помните, что политика write-back предпочтительна для L1-кэша и в данный момент недоступна для L2-кэша, который всегда создается в режиме write-through.
Write-through caching
Это режим, когда запись производится непосредственно в основную память и дублируется в кэш. Такой тип кэширования не ускоряет запись данных на диск (но и не замедляет), но существенно увеличивает скорость чтения данных, которые можно взять из кэша. Этот тип кэша безопасен с точки зрения надежности данных и дает однозначный выигрыш в производительности.
При использовании этого типа кэширования не будет потери данных в случае неисправности сервера и памяти. Блоки памяти кэша в этом случае всегда помечены как clean.
Рекомендации по использованию кэша
L1 Cache
Он решает следующие проблемы:
Запросы партнерского узла StarWind Virtual SAN могут приходить с небольшой задержкой и изменять порядок доступа к блокам, например, 1-2-3-4-5-6-7-8 изменится на 1-3-2-4-5-7-6-8. В этом случае L1- кэш сгладит поток последовательных запросов на запись с применением алгоритма round robin в дополнение к кэшированию. L1-кэш объединяет маленькие запросы записи в большие (write coalescing). Например, 16 запросов по 4k в кэш будут записаны на диск как единый блок 64к, что работает гораздо быстрее. Поэтому для такого кэша не нужно много памяти - от 128 МБ.
L1 также компенсирует перезапись в те же секторы диска. Самая частая перезапись - это небольшие по размеру операции. Размер кэша должен зависеть от от частоты перезаписи данных и размера working data set. Чем чаще перезапись, теперь меньше вы можете делать кэш, но если больше размер working data set, то должен быть и больше кэш. В этом случае работает формула Tcached = Tdisk * (1 – (cache size) / (working set size)). В этом случае, если у вас кэш составляет 0.1 от data working set, процессинг данных будет составлять 0.9 от времени процессинга данных на диск. Если же cache size = working data set, то средний процессинг команд будет примерно равен времени процессинга команд в памяти.
StarWind L1 cache в режимах write-back и write-through может быть использован для:
Файловых устройств StarWind HA image file на базе HDD-хранилищ в конфигурации RAID 10.
Также помните, что в большинстве случаев для дисковых массивов all-flash кэш уровня L1 вам не потребуется.
В идеале размер кэша L1 должен быть равен размеру working data set. Также размер кэша L1 влияет на время, которое вам потребуется, чтобы выключить сервер (нужно сбросить грязные блоки на диск). Также помните, что лучше не делать L1 кэш в режиме WB, чтобы не создавать ситуацию, когда большой объем данных может быть утерян.
При использовании кэша L1 в режиме write-back обязательно используйте UPS для серверов, чтобы не потерять часть данных. Время работы UPS должно позволяет сбросить содержимое грязного кэша на диск.
L2 Cache (Flash Cache)
Для обслуживания кэша L2 создается обычное устройство ImageFile device. У этого устройства нет таргета, и оно соединено с системой точно так же, как и устройство с данными (ImageFile or LSFS).
Система с кэшем L2 должна иметь больше оперативной памяти RAM для обеспечения накладных расходов. Формула тут такая: 6.5 ГБ RAM на 1 ТБ кэша L2, чтобы хранить метаданные. Более подробно о кэше L2 можно почитать в базе знаний StarWind.
StarWind L2 cache может быть использован для следующих сценариев:
HA-устройства StarWind image file на базе HDD в конфигурации RAID 10.
Устройства StarWind LSFS на базе HDD в конфигурации RAID 5, 6, 50, 60.
HA-устройства StarWind image file на all-flash хранилищах в некоторых сценариях. Более подробно об этих сценариях можно почитать в базе знаний StarWind.
В большинстве случаев, когда у вас есть L1 кэш, кэш уровня L2 вам не потребуется. Размер L2 кэша должен быть равен среднему объему уникальных данных, запрашиваемых с хранилища на регулярной основе (определяется экспериментально).
В своем финансовом отчете за второй квартал этого года компания Intel неожиданно объявила о том, что сворачивает (winding down) разработку технологии оперативной памяти Intel Optane. В свете падения квартальной выручки аж на 22% год к году, Intel просто не может поддерживать все перспективные технологии, требующие больших инвестиций в R&D.
Кстати, AMD во втором квартале этого года почти удвоила выручку (сказался еще эффект включения выручки приобретенной компании Xilinx):
Это оказалось, довольно-таки, неожиданной новостью для компании VMware, которая ориентировалась на поддержку этого типа памяти в своих продуктах, например, планируемом к выпуску решении Project Capitola. В данном продукте будет использоваться так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter.
В Project Capitola вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM. Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов.
На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. Однако в разработке технологий по виртуализации оперативной памяти компания VMware ориентировалась, в первую очередь, именно на Intel Optane.
Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте. В конце прошлого года мы писали о производительности этого типа памяти.
Теперь пользователи аппаратных устройств на базе Intel Optane продолжат получать стандартную поддержку Intel до окончания периода End-of-life, а также гарантию, действительную в течение 5 лет. Это касается следующих продуктовых линеек:
PMem 100 series ("Apache Pass")
PMem 200 series ("Barlow Pass")
DC P4800X SSD ("Cold Stream")
DC P5800X ("Alder Stream")
Также сообщается, что Intel продолжит развивать технологию PMem 300 series ("Crow Pass") для четвертого поколения процессоров Intel Xeon Scalable ("Sapphire Rapids").
VMware планирует продолжать поддержку памяти Intel Optane PMem в платформах vSphere 7.x и vSAN, а также будущих релизах этих продуктов. На данный момент память Optane поддерживается в трех режимах:
Обычная оперативная память (Memory mode)
App-Direct mode через механизм vPMem
Как персистентное хранилище через объекты vPMemDisk
VMware также добавила расширенные механизмы по поддержке vMMR в vSphere 7 Update 3 и добавила различные интеграции с механизмом DRS в следующей версии платформы. О технологии vMMR можно прочитать подробнее тут.
Также VMware поддерживает все предыдущие поколения технологии Intel Optane PMem, о чем можно почитать в KB 67645. Ну и VMware будет поддерживать будущее поколение Optane PMem 300, которое Intel, вроде как, не планирует сворачивать.
Ну а что касается Project Capitola, то VMware не будет поддерживать Intel Optane в этом решении, а переключится на технологии памяти стандарта CXL, который, как ожидается, получит большое распространение в отрасли. Посмотрим еще, что на эту тему еще расскажут на предстоящей конференции VMware Explore 2022.
В 2017 году компания VMware купила компанию VeloCloud, которая занималась продвижением технологии SD-WAN (software-defined WAN) для организации программно-определяемых WAN-сетей. Напомним, что для корпоративных онпремизных и облачных сетевых сред у VMware есть решение NSX, но решения VeloCloud предназначались для управления WAN-инфраструктурой компаний, которым было необходимо организовать и контролировать доступ пользователей из разных точек земного шара, с разных устройств и разных условиях защищенности и стабильности каналов, когда ресурсы организации, а также внешние SaaS-сервисы, находятся в географических разнесенных датацентрах. Сегодня мы поговорим об инфраструктуре VMware SASE - Secure Access Service Edge, которая призвана решить проблемы нового времени.
На днях компания VMware объявила о выпуске обновленной версии своего фреймворка для управления виртуальной инфраструктурой с помощью скриптов - PowerCLI 12.7. Напомним, что о прошлой версии PowerCLI 12.6 мы рассказывали вот тут.
Итак, давайте посмотрим на новые возможности PowerCLI 12.7:
1. Мультиплатформенный модуль VUM
Теперь модуль, предназначенный для обновлений компонентов виртуальной инфраструктуры, работает на платформах Linux и macOS, что очень давно просили пользователи. До этого момента оставалось только 2 модуля, которые не были портированы на эти ОС, теперь же PowerCLI стал полностью мультиплатформенным фреймворком (кстати, 40% всех его пользователей работают на Linux и macOS).
2. Улучшения модуля NSX
В PowerCLI 12.6 появился новый модуль NSX SDK, в этом же релизе для него появились функции поддержки последнего NSX API, включая удаленную аутентификацию в командлете Connect-NsxServer с использованием параметра -UseRemoteAuthentication. Также был улучшен механизм использования командлета Get-NsxOperation.
3. Новые параметры конфигурации кластера vSAN
Теперь для кластера vSAN можно установить пороговые значения для механизма health check, используя параметр -CapacityThreshold для командлетов Set-VsanClusterConfiguration и New-VsanHealthCheckThreshold. Например, так:
Также можно отключить/включить исторические данные vSAN health check, а также смонтировать/размонтировать датастор с другого кластера как удаленный датастор с помощью командлета Set-VsanClusterConfiguration.
Кроме перечисленного, в PowerCLI 12.7 появилось много небольших улучшений, таких как, например, увеличение производительности при работе с решениями SRM и HCX. Более подробный список улучшений приведен в Release Notes. Документация по работе с командлетами VMware PowerCLI 12.7 находится тут.
Компания VMware выкатила новую версию партнерского образовательного ресурса VMware Partner University. Напомним, что этот портал позволяет сотрудникам партнеров компании VMware получать информацию о продуктах и технологиях VMware, участвовать в образовательных программах по существующим и перспективным решениям, а также получать различного рода сертификации.
Давайте посмотрим, что нового в обновленном VMware Partner University:
Solution Learning Paths – теперь обучающиеся сотрудники партнеров разделены по уровням от новичков до экспертов в разрезе 5 областей, в которых находятся продукты и технологии VMware. Обучение предназначено для персонала в области продаж, маркетинга и технических специалистов. Также новые треки обучения для Customer Success и Practice Development будут доступны во второй половине 2023 финансового года (календарные даты 30 июля 2022 - 3 февраля 2023).
Academies – этот раздел содержит таргетированные материалы и контент курсов, которые предназначены для партнеров, ориентированных на отдельные вертикали. Например, сейчас есть специальные сайты для Telco и Security, а в новом финансовом году будут доступны новые порталы.
Dynamic Search – функции динамического поиска теперь позволяют искать курсы и материалы, отфильтрованные по семейству продуктов, их именам, разделам решений, доступности на конкретном языке, а также типу или активности (Hands-on Lab, LiveFire или vmLIVE).
Personalization functions – эти возможности позволяют пользователю продолжить навигацию по контенту, из которого он ушел, консолидировать регистрации на события и отслеживать их, а также сохранять его для будущего просмотра. Кроме того, можно видеть прогресс по завершению контента, скачивать описания материалов и просматривать, что появилось нового в области интересов этого пользователя.
Support Chat Bot - теперь для обращений в поддержку существенно уменьшилось время ответа (от одной недели до ответа почти в реальном времени), то есть партнеры теперь могут своевременно получать помощь в продвижении по выбранной траектории обучения.
Обновленная версия портала VMware Partner University доступна по этой ссылке.
В середине июня компания VMware представила сообществу Open Source свою новую разработку - нереляционную базу данных типа key-value SplinterDB. Базы данных с механиками "ключ-значение" работают очень быстро и в данный момент применяются для решения широкого круга задач. VMware сделала тут вот какую вещь - эта СУБД работает еще быстрее остальных (иногда в разы), поэтому она позиционируется как "ultra fast"-решение для высокопроизводительных нагрузок.
Платформа SplinterDB была разработана VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. Вот так это выглядит в сравнении с СУБД RocksDB (она была разработана в Facebook), которая работает в той же нише, что и SplinterDB, на примере бенчмарка Yahoo Cloud Services Benchmark (YCSB):
SplinterDB максимально использует возможности ядер процессоров, легко масштабируется и использует все преимущества технологии организации хранилищ NVMe. Поэтому SplinterDB можно использовать поверх существующих key-value хранилищ, а также традиционных реляционных баз данных, NoSQL-СУБД, микросервисов, обработчиков потоков, архитектуры edge/IoT, хранилищ метаданных и графовых баз данных.
SplinterDB - это внедренное key-value хранилище во внешней памяти, что означает, что приложения используют SplinterDB путем линковки библиотеки SplinterDB в свой исполняемый файл. SplinterDB хранит данные на высокопроизводительных дисках SSD NVMe и может масштабироваться до огромных датасетов, которые значительно превышают объемы доступной памяти RAM.
На картинке выше показан пример, где SplinterDB и RocksDB хранили датасет 80 GiB в системе, имеющей 4 GiB RAM. Так как лишь малая часть базы данных помещалась в кэш оперативной памяти, то эффективность работы подсистемы ввода-вывода была ключевым фактором оценки производительности. Для теста использовались диски Intel Optane SSD, которые поддерживают 2 GiB/sec на чтение и запись. При этом RocksDB использовала только 30% доступного канала обмена с хранилищем (для операций записи), а SplinterDB использовала до 90% канала. При чтении SplinterDB также показала себя в полтора раза лучше, чем RocksDB, за счет более эффективного использования CPU и техник кэширования.
В чем же секрет такого высокого уровня производительности? Дело в том, что современные key-value хранилища (включая SplinterDB, RocksDB, LevelDB, Apache Cassandra и другие) хранят данные в больших сортируемых таблицах. Запросы ищут значения в каждой таблице, спускаясь от новых данных к старым. Таким образом, запросы замедляют систему, накапливая все больше и больше таблиц с данными. Чтобы избежать замедления работы, эти системы время от времени объединяют несколько отсортированных таблиц в одну (это называется compaction). Это и создает дисбаланс между скоростью на чтение и скоростью на запись. За счет этого запросы исполняются быстро, но вот вставка данных замедляется. Если compaction делать реже, то вставка будет работать быстрее, но и чтение замедлится.
SplinterDB делает compaction более чем в 8 раз реже, чем RocksDB, поэтому вставка данных и работает в первой примерно в 7 раз быстрее, чем во второй. Но что со скоростью на чтение? Чтобы поддерживать высокую скорость чтения, SplinterDB работает иначе, чем современные хранилища. Большинство из них используют фильтры Bloom (или их еще называют cuckoo), чтобы ускорять запросы.
Фильтр - это маленькая структура данных, которая представляет некое множество из таблицы. RocksDB и аналоги используют один фильтр для каждой таблицы, и запросы прежде всего проверяют фильтр перед тем, как искать во всей таблице, чтобы большинство запросов могли искать только в небольшой структуре. Задумка здесь в том, что фильтры будут хранится в памяти, поэтому I/O операции с хранилищами будут вызываться нечасто.
На быстрых хранилищах этот подход работает не так эффективно, особенно когда набор данных в БД значительно превышает размер доступной оперативной памяти. На быстрых хранилищах затраты на CPU при поиске в фильтрах могут быть высокими ввиду большого числа фильтров. При этом может произойти ситуация, когда фильтры не помещаются в память, поэтому они отбрасываются на диск, что делает их использование в этом случае бесполезным.
SplinterDB использует новый вид фильтра, называемый routing filter. Один такой фильтр может заменить несколько фильтров типа Bloom, cuckoo или ribbon и может покрыть сразу несколько таблиц. Обычные фильтры могут сказать только, есть ли соответствующий ключ в доступности в данный момент или нет, а вот routing filter может не только сказать, что ключ есть, но и указать на то, какая конкретно из отсортированных таблиц его содержит. Поэтому запросам нужно делать гораздо меньше работы по поиску в фильтрах, а значит снижается нагрузка на CPU.
Кроме того, поиск в одном фильтре может сильно сэкономить на запросах ко многим таблицам, даже если этот фильтр занимает много места в RAM. Этот механизм работы с данными и был придуман в VMware. Все это позволяет существенно экономить на вычислительных мощностях для очень тяжелых и интенсивных нагрузок.
Многие администраторы виртуальных инфраструктур используют технологию NVIDIA vGPU, чтобы разделить физический GPU-модуль между виртуальными машинами (например, для задач машинного обучения), при этом используется профиль time-sliced vGPU (он же просто vGPU - разделение по времени использования) или MIG-vGPU (он же Multi-Instance vGPU, мы писали об этом тут). Эти два режима позволяют выбрать наиболее оптимальный профиль, исходя из особенностей инфраструктуры и получить наибольшие выгоды от технологии vGPU.
Итак, давайте рассмотрим первый вариант - сравнение vGPU и MIG vGPU при увеличении числа виртуальных машин на GPU, нагруженных задачами машинного обучения.
В этом эксперименте была запущена нагрузка Mask R-CNN с параметром batch size = 2 (training and inference), в рамках которой увеличивали число ВМ от 1 до 7, и которые разделяли A100 GPU в рамках профилей vGPU и MIG vGPU. Эта ML-нагрузка была легковесной, при этом использовались различные настройки профилей в рамках каждого тестового сценария, чтобы максимально использовать время и память модуля GPU. Результаты оказались следующими:
Как мы видим, MIG vGPU показывает лучшую производительность при росте числа ВМ, разделяющих один GPU. Из-за использования параметра batch size = 2 для Mask R-CNN, задача тренировки в каждой ВМ использует меньше вычислительных ресурсов (используется меньше ядер CUDA) и меньше памяти GPU (менее 5 ГБ, в сравнении с 40 ГБ, который имеет каждый GPU). Несмотря на то, что vGPU показывает результаты похуже, чем MIG vGPU, первый позволяет масштабировать нагрузки до 10 виртуальных машин на GPU, а MIG vGPU поддерживает на данный момент только 7.
Второй вариант теста - vGPU и MIG vGPU при масштабировании нагрузок Machine Learning.
В этом варианте исследовалась производительность ML-нагрузок при увеличении их интенсивности. Был проведен эксперимент, где также запускалась задача Mask R-CNN, которую модифицировали таким образом, чтобы она имела 3 разных степени нагрузки: lightweight, moderate и heavy. Время исполнения задачи тренировки приведено на рисунке ниже:
Когда рабочая нагрузка в каждой ВМ использует меньше процессора и памяти, время тренировки и пропускная способность MIG vGPU лучше, чем vGPU. Разница в производительности между vGPU и MIG vGPU максимальна именно для легковесной нагрузки. Для moderate-нагрузки MIG vGPU также показывает себя лучше (но немного), а вот для тяжелой - vGPU уже работает производительнее. То есть, в данном случае выбор между профилями может быть обусловлен степенью нагрузки в ваших ВМ.
Третий тест - vGPU и MIG vGPU для рабочих нагрузок с высокой интенсивность ввода-вывода (например, Network Function with Encryption).
В этом эксперименте использовалось шифрование Internet Protocol Security (IPSec), которое дает как нагрузку на процессор, так и на подсистему ввода-вывода. Тут также используется CUDA для копирования данных между CPU и GPU для освобождения ресурсов процессора. В данном тесте IPSec использовал алгоритмы HMAC-SHA1 и AES-128 в режиме CBC. Алгоритм OpenSSL AES-128 CBC был переписан в рамках тестирования в части работы CUDA. В этом сценарии vGPU отработал лучше, чем MIG vGPU:
Надо сказать, что нагрузка эта тяжелая и использует много пропускной способности памяти GPU. Для MIG vGPU эта полоса разделяется между ВМ, а вот для vGPU весь ресурс распределяется между ВМ. Это и объясняет различия в производительности для данного сценария.
Основные выводы, которые можно сделать по результатам тестирования:
Для легковесных задач машинного обучения режим MIG vGPU даст бОльшую производительность, чем vGPU, что сэкономит вам деньги на инфраструктуру AI/ML.
Для тяжелых задач, где используются большие модели и объем входных данных (а значит и меньше ВМ работают с одним GPU), разница между профилями почти незаметна.
Для тяжелых задач, вовлекающих не только вычислительные ресурсы и память, но и подсистему ввода-вывода, режим vGPU имеет преимущество перед MIG vGPU, что особенно заметно для небольшого числа ВМ.
В апреле компания VMware выпустила обновление своего основного фреймворка для управления виртуальной инфраструктурой и ее компонентами из командной строки PowerCLI 12.6. О прошлой версии PowerCLI 12.5 мы писали в январе вот тут, а сегодня расскажем, что появилось нового в весеннем обновлении.
Основные улучшения и нововведения:
1. Байндинги PowerShell для интерфейсов NSX Policy Manager API.
Теперь появился новый модуль VMware.Sdk.Nsx.Policy, который реализует байндинг PowerShell для программных интерфейсов NSX Policy Manager API.
2. Новые командлеты для управления виртуальным модулем vCenter Server Appliance.
Теперь для управления резервными копиями vCenter Server Appliance можно использовать следующие командлеты:
New-ApplianceBackupJob - стартует задачу резервного копирования на уровне файлов vCenter Server на бэкап-сервер.
Wait-ApplianceBackupJob - мониторит прогресс задачи резервного копирования и возвращает в ApplianceBackupJob.
Get-ApplianceBackupJob - получает список завершенных или находящихся в исполнении задач резервного копирования.
Get-ApplianceBackupPart - получает список частей (parts), которые могут быть включены в задачу РК, а также их размер в резервной копии. Обязательные части всегда включаются в бэкап.
3. Поддержка SRM 8.5.
Модуль VMware.VimAutomation.Srm был обновлен и теперь поддерживает решение VMware Site Recovery Manager 8.5.
4. Исправления ошибок.
VMware приводит таблицу с багофиксами:
Product /Category
Cmdlet Name
Description
Status
HCX
New-HCXMigration
VM with multiple networks attached and if migration is triggered without mapping all the source networks to the target, the validation does not throw an error
Fixed
HCX
New-HCXMigration
Initiating a Non-Mobility migration using New-HCXMigration cmdlet does not show the network mapping in the migration dashboard UI
Fixed
vSAN
Get-VsanView
Get-VsanView throws ‘Object reference not set to an instance of an object.’ on PowerShell 7.2.2.
Fixed
HCX
Get-HCXVM
Get-HCXVM cmdlet throws “Unexpected character encountered while parsing value: <. Path ”, line 0, position 0..” when the number of VMs available in the inventory is very big
Fixed
HCX
Get-HCXMigration
Get-HCXMigration cmdlet throws an error if any of the migrations were triggered without providing the ‘TargetStorageProfile’ param
Fixed
Загрузить компоненты фреймворка VMware PowerCLI 12.6 можно по этой ссылке. Release notes доступны тут.
Многие из вас знают компанию StarWind Software, лидера в сфере поставки программных и программно-аппаратных решений для создания отказоустойчивых хранилищ. Помимо решений непосредственно для организации хранилищ, у компании есть и виртуальный модуль StarWind Backup Appliance, который предназначен для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе оборудования NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.
Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.
В апреле компания StarWind объявила, что StarWind Backup Appliance теперь включает в себя оборудование GRAID SupremeRAID - первую в мире карточку NVMe-oF RAID, которая обеспечивает высочайший уровень защиты данных в рамках технологии NVMe RAID на рынке.
Диски NVMe SSD постепенно становятся стандартом индустрии хранения данных, а решение для резервного копирования StarWind BA уже использует полностью только NVMe-хранилища. В этих системах была только одна проблема - с надежной реализацией RAID, и вот теперь она решена с помощью GRAID.
Традиционные RAID-контроллеры не были разработаны изначально для технологии NVMe, а программные RAID работают недостаточно эффективно, потребляя при этом большое число циклов CPU, что мешает рабочим нагрузкам сервера. Поэтому с теперь помощью карточек GRAID комплексы StarWind Backup Appliance обеспечат максимальную производительность и защиту данных на базе дисков NVMe SSD.
Вот так выглядят результаты тестов технологии GRAID по сравнению с текущими реализациями аппаратных RAID для NVMe:
Более подробно об этом нововведении можно узнать из пресс-релиза StarWind. Скачать пробную версию StarWind Backup Appliance можно по этой ссылке.
Недавно компания VMware опубликовала интересное тестирование, посвященное работе и масштабированию высокопроизводительных нагрузок (High Performance Computing, HPC) на платформе VMware vSphere 7.
Основной целью тестирования было сравнение нативной производительности HPC-нагрузок на голом железе (bare metal) с работой этих машин на платформе vSphere.
Рабочие нагрузки использовали message passing interface (MPI) с приложениями на базе параллельных процессов (MPI ranks), которые могли объединять несколько физических серверов или виртуальных машин для решения задач. Например, использовались задачи computational fluid dynamics (CFD) для моделирования воздушных потоков в автомобильной и авиа индустриях.
В качестве тестового стенда использовался HPC-кластер из 16 узлов на базе Dell PowerEdge R640 vSAN ReadyNodes в качестве масштабируемых блоков. R640 представлял собой одноюнитовый сервер с двумя процессорами Intel Xeon.
Топология кластера выглядела следующим образом:
Коммутаторы Dell PowerSwitch Z9332 соединяли адаптеры NVIDIA Connect-X6 на скорости 100 GbE по интерфейсу RDMA для MPI-нагрузок.
Отдельная пара коммутаторов Dell PowerSwitch S5248F 25 GbE top of rack (ToR) использовалась для сети управления гипервизором, сети vSAN и доступа к ВМ.
Для соединений использовался virtual link trunking interconnect (VLTi). В рамках теста был создан кластер vSAN с поддержкой RDMA.
Конфигурация физических адаптеров выглядела следующим образом:
Вот так выглядит набор HPC-приложений и бенчмарков из разных индустрий, на базе которых проводилось тестирование:
В процессе тестирования производилось масштабирование высокопроизводительного кластера от 1 до 16 узлов, а результаты фиксировались для физической платформы и для виртуальной среды.
Итак, первая задача о динамике жидкостей:
Вторая задача - моделирование прогнозов погоды:
Третья задача - молекулярная динамика (тут на 16 узлах уже есть отличие производительности до 10%):
Еще один бенчмарк по молекулярной динамике, тут тоже есть 10%-е падение производительности на виртуальной платформе, но заметно его становится только при большом количестве узлов:
Бенчмарк NAMD, тут все почти одинаково:
Конечно же, в процессе тестирования производился тюнинг различных настроек самой платформы vSphere и виртуальных машин, вот какие настройки использовались:
Вот так это выглядит в интерфейсе vSphere Client:
Полную версию отчета о тестировании вы можете посмотреть здесь, но из картинок выше вполне понятно, что платформа VMware vSphere и решение vSAN отлично оптимизированы для работы с высокопроизводительными вычислениями.
RSS
